gRPC 微服务构建之链路追踪（OpenTracing）

前一篇文章 微服务基础之 链路追踪（OpenTracing），介绍了 OpenTracing 的理论，本文基于 gRPC 与 Zipkin && Jaeger 来实现 Tracing 的应用。

一个 Tracer 包含了若干个 Span，Span 是追踪链路中的基本组成元素，一个 Span 表示一个独立的工作单元，在链路追踪中可以表示一个接口的调用，一个数据库操作的调用等等。

一个 Span 中包含如下内容：

详细说明下上面的字段：

1、Tags 每个 Span 可以有多个键值 K/V 对形式的 Tags，Tags 是没有时间戳的，支持简单的对 Span 进行注解和补充。Tags 是一个 K/V 类型的键值对，用户可以自定义该标签并保存。主要用于链路追踪结果对查询过滤。如某 Span 是调用 Redis ，而可以设置 redis 的标签，这样通过搜索 redis 关键字，可以查询出所有相关的 Span 以及 trace；又如 http.method="GET",http.status_code=200，其中 key 值必须为字符串，value 必须是字符串，布尔型或者数值型。Span 中的 Tag 仅自己可见，不会随着 SpanContext 传递给后续 Span。

2、Logs Logs 也是一个 K/V 类型的键值对，与 Tags 不同的是，Logs 还会记录写入 Logs 的时间，因此 Logs 主要用于记录某些事件发生的时间。

PS：Opentracing 给出了一些惯用的 Tags 和 Logs，链接

3、SpanContext（核心字段） 每个 Span 必须提供方法访问 SpanContext，SpanContext 代表跨越进程边界（在不同的 Span 中传递信息），传递到下级 Span 的状态。SpanContext 携带着一些用于跨服务通信的（跨进程）数据，主要包含：

4、Baggage Items Baggage Items 与 Tags 类似，也是 K/V 键值对。与 tags 不同的是：Baggage Items 的 Key 和 Value 都只能是 string 格式，Baggage items 不仅当前 Span 可见，其会随着 SpanContext 传递给后续所有的子 Span。要小心谨慎的使用 Baggage Items：因为在所有的 Span 中传递这些 Key/Value 会带来不小的网络和 CPU 开销。Baggage 是存储在 SpanContext 中的一个键值对集合。它会在一条追踪链路上的所有 Span 内全局传输，包含这些 Span 对应的 SpanContexts

5、References（引用关系） Opentracing 定义了两种引用关系: ChildOf 和 FollowFrom，分别来看：

6、Trace Trace 表示一次完整的追踪链路，trace 由一个或多个 Span 组成。它表示从头到尾的一个请求的调用链，它的标识符是 traceID。 下图示例表示了一个由 8 个 Span 组成的 trace:

以时间轴的展现方式如下：

此外，跟踪上下文（Trace Context）也是很重要的场景，它定义了传播跟踪所需的所有信息，例如 traceID，parent-SpanId 等。OpenTracing 提供了两个处理跟踪上下文（Trace Context）的方法：

在 OpenTracing API 中，有三个主要对象：

Zipkin 是一款开源的分布式实时数据追踪系统（Distributed Tracking System），由 Twitter 公司开发和贡献。其主要功能是聚合来自各个异构系统的实时监控数据。在链路追踪 Tracing Analysis 中，可以通过 Zipkin 上报 Golang 应用数据。

使用 Zipkin 上报数据的流程如下图所示：

使用的 package：

下面介绍通过 Zipkin 将 Golang 应用数据上报至链路追踪控制台的方法： 1、创建 Tracer，Tracer 对象可以用来创建 Span 对象（记录分布式操作时间）。Tracer 对象还配置了上报数据的网关地址、本机 IP、采样频率等数据，您可以通过调整采样率来减少因上报数据产生的开销。

2、记录请求数据，下面代码用于记录请求的根操作：

如果需要记录请求的上一步和下一步操作，则需要传入上下文。如下代码所示，childSpan 为 span 的孩子节点：

3、可选：（为了快速定位问题）可以为某个记录添加一些自定义标签（Tags），例如记录是否发生错误、请求的返回值等：

4、在分布式系统中发送 RPC 请求时会带上 Tracing 数据，包括 TraceId、ParentSpanId、SpanId、Sampled 等。可以在 HTTP 请求中使用 Extract/Inject 方法在 HTTP Request Headers 上透传数据。即 在 Client 端执行 `Inject`，在 Server 端执行 `Extract`， 目前 Zipkin 已有组件支持以 HTTP、gRPC 这两种 RPC 协议透传 Context 信息。总体数据流程如下：

这里以 HTTP 为例，在客户端调用 Inject 方法传入 Context 信息：

在服务端调用 Extract 方法解析 Context 信息：

本小节介绍使用 Jaeger 来实现链路追踪。Jaeger 是 Uber 开源的分布式追踪系统，也是遵循 Opentracing 的系统之一。

1、Jaeger 提供了 all-in-one 镜像，方便我们快速开始测试：

2、初始化 Jaeger tracer，设置 endpoint / 采样率等信息

3、创建 tracer，生成 Root Span，下面这段代码创建了一个 Root span，并将该 Span 通过 context 传递给 Foo 方法，以便在 Foo 方法中将追踪链继续延续下去：

4、Foo、Bar 方法模拟了独立的子操作 Span，Foo 方法调用了 Bar，假设在 Bar 中发生了一些错误，可以通过 span.LogFields 和 span.SetTag 将错误记录在追踪链中。StartSpanFromContext 这个方法看起来是直接从 ctx 中拿到 Span 并继承？

最后，简单看下 StartSpanFromContext 的 实现，印证了上面的猜想：

小结下上面的过程，如果要确保追踪链在程序中不断开，需要将函数的第一个参数设置为 context.Context，通过 opentracing.ContextWithSpan 将保存到 context 中，通过 opentracing.StartSpanFromContext 开始一个新的子 span，然后设置直到调用流程结束。

假设我们需要在 gRPC 服务中调用另外一个微服务（如 RESTFul 服务），该如何跟踪？简单来说就是使用 HTTP 头作为媒介（Carrier）来传递跟踪信息（traceID）。下一小节，来看下 gRPC 中的 Opentracing 实现。

本小节，介绍下 gRPC 与 OpenTracing 的结合使用，跟踪一个完整的 RPC 请求，从客户端到服务端的实现。分为两种：

客户端的实现如下所示：

下面是服务端代码，同样使用拦截器 OpenTracingServerInterceptor 来构建，服务端的 RPC 方法中包含了一次对 Database 的请求。

前一节，说到跨进程传递 Trace 的时候需要进行的 Inject 和 Extract 操作，上面的示例代码并没有出现。那么客户端 / 服务端如何实现对 Span 的 Inject/Extract 呢？答案就是拦截器 otgrpc.OpenTracingServerInterceptor/OpenTracingClientInterceptor 方法，这里以 OpenTracingClientInterceptor 方法为例：

从客户端 injectSpanContext 的实现来看，最终在 RPC 调用前，通过 metadata.NewOutgoingContext 将 Context 信息（包含了 Tracer），即获取了跟踪上下文并将其注入 HTTP 头，因此我们不需要再次调用 Inject 函数。而在服务器端，从 HTTP 头中 Extract 跟踪上下文并将其放入 Golang context 中，无须手动调用 Extract 方法。

但对于其他基于 HTTP 的服务（如 RESTFul-API 服务），情况就并非如此，需要写代码从服务器端的 HTTP 头中提取跟踪上下文，亦或也使用拦截器实现，如 Kratos 的 bm 框架的 Trace 拦截器

见此，Xorm 实现 tracing 机制

这里引用下阿里云推荐的 traceId 生成规则：

TraceId 一般由接收请求经过的第一个服务器产生。规则是：服务器 IP + ID 产生的时间 + 自增序列 + 当前进程号（忽略 | 号），如 0ad1348f|1403169275002|1003|56696：

SpanId 代表本次调用在整个调用链路树中的（相对）位置。

假设一个 Web 系统 A 接收了一次用户请求，那么在这个系统日志中，记录下的 SpanId 是 0，代表是整个调用的根节点，如果 A 系统处理这次请求，需要通过 RPC 依次调用 B、C、D 三个系统，那么在 A 系统的客户端日志中，SpanId 分别是 0.1，0.2 和 0.3，在 B、C、D 三个系统的服务端日志中，SpanId 也分别是 0.1，0.2 和 0.3；如果 C 系统在处理请求的时候又调用了 E，F 两个系统，那么 C 系统中对应的客户端日志是 0.2.1 和 0.2.2，E、F 两个系统对应的服务端日志也是 0.2.1 和 0.2.2。如果把一次调用中所有的 SpanId 收集起来，可以组成一棵完整的链路树。

在实现 tracing 逻辑的时候，一定要注意 Span 是否跨进程！二者的实现是不同的：

官方给出了4种常用例子：

1、Creating a Span given an existing Go context.Context If you use context.Context in your application, OpenTracing’s Go library will happily rely on it for Span propagation. To start a new (blocking child) Span, you can use StartSpanFromContext.

2、Starting an empty trace by creating a “root span”

3、Creating a (child) Span given an existing (parent) Span

4、Serializing to the wire 跨进程Inject：

4、Deserializing from the wire 跨进程Extract：

先看 StartSpanFromContext 方法的定义：

可以看到StartSpanFromContext方法的第2个返回值最终来源于ContextWithSpan的context.WithValue，就是使用StartSpanFromContext创建了子Span的时候，同时生成了一个子context，用于后续的进程内tracing的context上下文，如果在之后还需要启动进程内的函数调用，那么就需要传入这个新的context（而不是创建之前的context），如果不需要的话，那么可以忽略掉这个返回值

下图演示了一个HTTP->RPC的调用路径上的Span传递方法：

小结下，要实现 Tracing 机制及 Tracing 应用的关键点：